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PROCEDE FT SYSTEME DE GESTTON D' AUTHORISATION D'AC CES 
tvttm TTTITTSATEUR ATT NIVEAU TTITN DOM A IMF, ADMINISTRATIF 
t nr AT . T .fYR S D'UNE CONNEXION B E L'UTILISATEI JR A UN RESEAU 
5 IR 

La presente invention concerne la fourniture de services bases sur un transport 
IP (Internet Protocol) tels que la connexion au reseau Internet ou la telephonie 
sur IP. 

10 

Elle s'applique notamment aux architectures basees sur le protocole RADIUS 
(Remote Authentication Dial In User Service) qui sont largement deploy6es 
dans les r6seaux IP pour gerer les droits d'acces des utilisateurs et le comptage 
necessaire a la facturation de ces derniers pour un domaine administratif donne. 

15 Dans ce contexte, un domaine administratif regroupe 1' ensemble des 
Squipements reseau geres par un meme aclministrateur r6seau. Ces architectures 
sont egalement utilisees pour gerer l'acces aux reseaux des utilisateurs en 
situation d'itinerance (roaming), c'est-a-dire connectes depuis un r6seau 
appartenant a un domaine administratif different de celui dont ils dependent, la 

20 gestion de Pautorisation etant alors effectuee entre domaines administratifs. 

Dans le cadre des architectures permettant l'acces a des services IP par 
l'intermediaire de technologies telles que ADSL (Asymmetric Digital 
Subscriber Line), WLAN (Wireless Local Area Network), et WAP (Wireless 

25 Application Protocol), au moins deux domaines administratifs participent a la 
gestion d'autorisation d'acces. II s'agit du domaine administratif local, c'est-a- 
dire celui auquel l'utilisateur se connecte et d'un domaine administratif distant, 
c'est-a-dire celui du fournisseur d'acces au reseau IP ou de services auquel il 
desire acc6der. Dans ces architectures, le domaine administratif local joue 

30 essentiellement le r61e d' intermediate entre l'utilisateur et le domaine 
administratif de son fournisseur de service. 

Le protocole RADIUS qui est concu essentiellement sur le modele 
client/serveur, permet de gerer les droits d'acces d'un utilisateur d'un reseau IP. 
35 Dans les architectures mentionnees ci-avant, l'utilisateur se connecte tout 
d'abord a un serveur d'acces d'un reseau local, ce serveur possedant un client 
RADIUS charge de recuperer les informations foumies lors de sa demande 
d'acces et de transmettre ces informations dans un message de type requete 
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d'acces (Access-Request) a un serveur d'authentification du reseau d'acces, 
possedant un serveur RADIUS. Le serveur d'authentification assure le 
traitement des requdtes d'acces en authentifiant les utilisateurs en fonction des 
informations dont il dispose, et fournit en reponse, soit une autorisation d'acces 
sous la forme d'un message d' acceptation d'acces (Access-Accept), soit un 
refus d'acces sous la forme d'un message de refus d'acces (Access-Reject) 
contenant la raison du refus. Le message d' autorisation d'acces contient toutes 
les informations necessaires au serveur d'acces pour fournir le service final a 
l'utilisateur et notamment les informations sur la configuration d'acces. 



En plus des messages mentionnes ci-avant, le protocole RADR7S prevoit 
egalement un message de defi d'acces (Access-Challenge) permettant au 
serveur d'authentification d'envoyer au serveur d'acces une valeur de defi non- 
predictible. A la reception d'un tel message, le serveur d'acces demande a 

15 l'utilisateur de lui fournir une valeur de reponse obtenue en appliquant a la 
valeur de d6fi un algorithme predefini. Sur reception de cette reponse, le serveur 
d'acces emet a destination du serveur d'authentification un nouveau message de 
requ&e d'acces contenant la valeur de reponse. Ce nouveau message de requete 
d'acces est trait6 par le serveur d'authentification qui y repond en envoyant un 

20 message d'acceptation ou de refus d'acces, selon la valeur de reponse fournie . 
par l'utilisateur. Le serveur d'authentification peut egalement repondre par un 
message de defi d'acces (Access Challenge) 

Si le serveur d'authentification du reseau d'acces, appele par le serveur d'acces 
25 ne dispose pas des informations necessaires au traitement de la demande 
d'acces emise par l'utilisateur, il peut s'adresser a un serveur d'authentification 
approprie en se comportant comme un serveur mandataire (proxy) RADIUS qui 
ne fait que retransmettre les messages entre le serveur d'acces et un autre 
serveur d'authentification. II peut ainsi assurer le rdle d'aiguillage des messages 
30 RADIUS qui transitent par lui vers plusieurs serveurs d'authentification. II peut 
egalement assurer la fonction de filtrage de ces messages et en modifier le 
contenu (par ajout, suppression ou modification des attributs) sans pour autant 
pouvoir en modifier la nature. 

35 Le rdle d'un serveur proxy RADIUS tel que prevu dans le protocole RADIUS 
est done tres limited Or un tel serveur peut avoir besoin d'exercer un controle 
renforce sur la signalisation et eventuellement declencher une authentification 
locale. En particulier, un tel serveur mandataire n'a pas la possibility d'initier 
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sur reception d'un message de requete d'acces un echange de type defi/reponse 
avec un client RADIUS, et ce independamment d'un serveur d'aumentification 
distant. 

Dans de nombreuses applications, il est pourtant souhaitable de pouvoir 
authentifier un utilisateur non seulement au niveau distant, mais egalement au 
niveau local, notamment pour pouvoir proposer aux utilisateurs des services 
supplementaires au niveau local, en plus d'un acces a un reseau public tel que le 
reseau Internet. 

La presente invention a pour but de supprimer ces inconvenients. Cet objectif 
est atteint par la prevision d'un procede de gestion d'autorisation d'un utilisateur 
lors d'une tentative d'acces a un reseau de transport IP par l'intermediaire d'un 
reseau d'acces, ce procede comprenant des etapes au cours desquelles : 



15 



- un terminal d'utilisateur emet a destination d'un fournisseur d'acces ou de 
service IP une requete d'acces contenant des donnees d'authentification de 
l'utilisateur aupres du fournisseur d'acces ou de service IP, qui est transmise 
par l'intermediaire d'un serveur d'acces du reseau d'acces et du reseau de 

20 transport IP, en vue d'etre adressee a un serveur d'authentification distant du 
fournisseur d' acces ou de service IP, 

- sur r6ception de la requete d'acces, le serveur d'acces emet une requete 
RADIUS conforme au protocole RADIUS a un serveur proxy du reseau 
d'acces, 

25 - sur reception de la requete RADIUS, le serveur proxy 6met une demande 
d'autorisation d'acces au serveur d'authentification distant, 

- le serveur d'authentification distant execute une procedure d'authentification 
de l'utilisateur, sur la base des donnees d'authentification contenues dans la 
requ€te d'acces, et transmet en reponse au serveur proxy un message de 

30 reponse contenant le r6sultat de la procedure d'authentification de 
l'utilisateur. 

Selon l'invention, ce procede comprend en outre des etapes au cours 
desquelles : 



35 



- le serveur proxy determine pour chaque requete RADIUS, recue du serveur 
d'acces et correspondant a une requete d'acces emise par un terminal 
d'utilisateur, si une authentification locale de l'utilisateur emetteur de la 
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requ6te d'accds, au niveau du reseau local doit etre effectuee, 
- si une authentification locale de l'utilisateur doit etre effectuee, le serveur 
proxy emet a destination du serveur d'acces une demande de donnees 
d'authentification qui est retransmise au terminal de l'utilisateur, recoit un 
message de reponse du terminal d'utilisateur par l'intermediaire du serveur 
d'accds, et execute une procedure d'authentification locale de l'utilisateur, 
sur la base des donnees d'authentification contenues dans le message de 
reponse. 



Selon un mode de realisation prefer^ de l'invention, la demande de donnees 
d'authentification emise par le serveur proxy a destination du terminal de 
l'utilisateur si une authentification locale de l'utilisateur doit etre effectu6e, est 
un message de defi contenant un nombre aleatoire. 

Avantageusement, le message de d6fi contient une indication permettant au 
terminal de l'utilisateur de determiner qu'il concerne une authentification locale 
de l'utilisateur. 



Selon un mode de realisation prefer^ de 1'invention, l'authentification distante 
20 de l'utilisateur par le serveur d'authentification distant comprend des etapes au 
cours desquelles : 

- le serveur d'authentification distant emet en direction de l'utilisateur un 
message de defi contenant un nombre aleatoire, 

25 - le serveur proxy retransmet le message de defi emis par le serveur 
d'authentification distant en direction de l'utilisateur et recoit dans un 
message de r6ponse les donnees d'autbentification de l'utilisateur auprds du 
serveur d'authentification distant, 

- le serveur proxy retransmet au serveur d'authentification distant le message 
30 de reponse 6mis par le terminal de l'utilisateur, 

- le serveur proxy recoit du serveur d'authentification distant un message de 
resultat de 1 ' authentification de l'utilisateur. 



Selon un mode de realisation prefere de l'invention, le serveur proxy determine 
quels droits d'acces attribuer a l'utilisateur en fonction du resultat des 
authentifications locale et distante de l'utilisateur. 

L'invention concerne egalement un systeme de gestion d'autorisation d'un 
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utilisateur lors d'une tentative d'acces d'un terminal d'utilisateur a un 
fournisseur d'acces ou de service IP par l'mtermediaire d'un reseau de transport 
IP, le systeme comprenant : 

5 - des reseaux d'acces auxquels sont connectes les terrninaux d'utilisateurs, 

- des passerelles IP assurant la liaison respectivement entre les reseaux d'acces 
et le r6seau de transport IP, 

- au moins un serveur d'acces par reseau d'acces, concu pour emettre a la 
demande des terrninaux d'utilisateur des requites d'acces RADIUS 

1 0 conformes au protocole RADIUS, 

- au moins un serveur d'authentification distant pour chacun des fournisseurs 
d'acces ou de service IP, concu pour authentifier les utilisateurs en fonction 
de donnees d'authentification contenues dans des requ&es d'acces recues par 
le serveur d'authentification, et 

15 - un serveur proxy connecte au reseau de transport IP concu pour retransmettre 
chaque requete d'acces RADIUS, emise par l'un des serveurs d'acces a la 
demande d'un utilisateur, vers un serveur d'authentification distant de 
fournisseur d'acces ou de service IP indique dans la requite d'acces, et 
retransmettre vers les serveurs d'acces les reponses d'authentification 

20 fournies par les serveurs d'authentification distant. 

Selon 1'invention, le serveur proxy comprend : 

- des moyens pour determiner pour chaque requete d'acces RADIUS recue 
25 d'un serveur d'acces a la demande d'un utilisateur, si une aumentification 

locale de l'utilisateur emetteur de la requete d'acces doit ou non etre 
effectuee au niveau du reseau local, 

- des moyens pour emettre par l'mtermediaire d'un serveur d'acces a 
destination d'un terminal d'utilisateur devant Stre authentifie localement, un 

30 message de demande de donnees d'authentification, et pour recevoir en 
reponse du terminal d'utilisateur un message de reponse contenant les 
donnees d'authentification demandees, et 

- des moyens pour executer une procedure d'authentification locale de 
l'utilisateur, sur la base des informations d'authentification contenues dans le 

35 message de reponse. 



Selon un mode de realisation prefere de l'invention, le serveur proxy comprend 
en outre des moyens pour determiner un resultat global d'authentification en 
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fonction du resultat de l'authentification locale de 1'utilisateur et de la reponse 
d'authentification de 1'utilisateur fouraie par le serveur d'authentification, et 
pour retransmettre le resultat global d'authentification vers le serveur d' acces. 

5 Selon un mode de realisation prefere de Invention, chaque serveur d'acces 
comprend un client RADIUS et le serveur proxy comprend un client et un 
serveur RADIUS, pour echanger des messages conformes au protocole 
RADIUS. 



1 0 Selon un mode de realisation prefere de Invention, le message de demande de 
donnees d'authentification emis par le serveur proxy pour authentifier 
localement 1'utilisateur est un message de defi, le serveur proxy comportant des 
moyens pour generer un nombre aleatoire qui est insert dans le message de defi, 
et des moyens pour verifier la reponse au message de defi recue du terminal de 

15 1'utilisateur. 



Selon un mode de realisation prefer^ de l'invention, le serveur proxy comprend 
des moyens pour determiner quels droits d'acces attribuer a 1'utilisateur en 
fonction du resultat des authentifications locale et distante de 1'utilisateur 

20 

Un mode de realisation prefere de l'invention sera d6crit ci-apres, a titre 
d'exemple non limitatif, avec reference aux dessins annexes dans lesquels : 

La fig" 1 " 6 1 represente schematiquement 1' architecture d'un 
25 systeme de fourniture de services bases sur un transport IP, selon 

l'invention ; 

Les figures 2a et 2b represented un diagramme de sequencement 
d'etapes qui sont executees dans le systeme represente sur la 
figure 1, conform6ment au procede selon l'invention. 

30 Le systeme represente sur la figure 1 comprend des reseaux d'acces 1, 2 
auxquels sont connect6s des termmaux 11, 12, 13 d'utilisateurs. Ces reseaux 
d'acces 1, 2 fournissent aux terminaux un acces a un r6seau de transport IP 5 
par l'intermediaire de passerelles IP 3, 4, respectives adaptees au reseau 
d'acces. Le reseau de transport IP 5 permet aux utilisateurs d'acceder a un 

35 fournisseur d'acces Internet 6, 7 ou a un fournisseur de services IP 8. 
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Selon 1'invention, ce systeme comprend en outre des serveurs d'acces 9 
connectes respectivement aux reseaux locaux 1, 2, auxquels les utilisateurs 
souhaitant acceder au reseau IP doivent se connecter, et un serveur proxy 
d'authentification 10 connecte au reseau de transport IP 5 et auquel chaque 
5 serveur d'acces 9 transmet les requetes d'acces emises par les terminaux 11,12, 
13. 

Chaque serveur d'acces 9 est concu pour recevoir toutes les requetes d'acces a 
un fournisseur 6, 7, 8 d'acces ou de service, emises par les utilisateurs sur le 
10 reseau local 1, 2 correspondant, et d'aiguiller ces requetes par l'interm6diaire 
d'une passerelle 3, 4 au travers du reseau de transport IP vers le fournisseur 6, 
7, 8 d'acces ou de service indiqu6 dans la requete par le terminal de l'utilisateur, 
chaque fournisseur d'acces ou de service disposant d'un serveur 
d'authentification 15. 

15 

Lorsqu'un terminal d'utilisateur 11, 12, 13 tente d' acceder au reseau local, le 
logiciel de navigation Internet est par exemple automatiquement redirige vers 
un serveur Web jouant le rdle de serveur d'acces 9 qui execute la proc6dure 
d'authentification d'acces illustree sur les figures 2a et 2b. 

20 

Cette procedure est conforme au protocole RADIUS. Ainsi, le serveur d'acces 9 
integre un client RADIUS pour pouvoir recevoir des messages RADR7S et y 
repondre. Le serveur proxy 10 possede egalement toutes les fonctionnalites d'un 
proxy tel que decrit dans la norme RADIUS. 

25 

Dans toute la description qui suit de la proc6dure d'authentification, les 
identifiants de messages ou requetes RADIUS employes sont donnes a titre 
d'exemple. Dans la norme RADIUS le terme "type" determine la nature du 
message. 

30 

A la premiere etape 21, le serveur d'acces 9 emet a destination du serveur proxy 
d'authentification 10 situe dans le domaine administratif local, une requete 
d'acces 41 du type RADIUS Access-Request comportant un identifiant egal a 
128. A la reception d'un tel message a l'etape 22, le serveur proxy 10 memorise 
35 et analyse le contenu de ce message pour determiner si l'utilisateur doit etre 
authentifie localement (etape 23). 

Ainsi, une authentification locale peut par exemple etre declenchee si la requete 
d'acces provient d'un reseau local particulier, ou en fonction d' informations 
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d'identification de 1'utilisateur contenues dans la requSte. 

Si 1'utilisateur doit etre authentifie localement, le serveur proxy 10 emet a 
destination du serveur d'acces 9 a l'etape 24 un message de defi 44 du type 
5 RADIUS Access-Challenge comportant un identifiant egal a 128. Ce message 
contient 6galement une valeur non predictible par exemple generee 
aleatoirement par le serveur proxy 10 ou par un equipement distinct qui peut 
etre un centre d'authentification, et un attribut precisant l'origine du message, a 
savoir le domaine administratif local. A cet effet, on peut utiliser les attributs de 
1 0 type "Vendor-Specific", ou les attributs "State" ou "Reply-Message" pr6vus par 
le protocole RADIUS. 

A l'etape suivante 25, le serveur d'acces 9 recoit le message de defi 44, identifie 
l'emetteur du message a l'aide de l'attribut precisant l'origine du message, et 

15 done demande a 1'utilisateur de lui fournir une reponse a la demande 
d'authentification locale. Cette reponse peut contenir une valeur de reponse 
obtenue en appliquant a la valeur aleatoire contenue dans le message de defi un 
algorithme de cryptage predefini faisant intervenir une cle secrete propre a 
1'utilisateur, le serveur proxy disposant de moyens pour determiner si la valeur 

20 de reponse correspond a la valeur aleatoire et a la cle secrete de 1'utilisateur. 

A l'etape suivante 26, le serveur d'acces transmet au serveur proxy 10 une 
nouvelle requete d'acces 46 contenant la reponse a la demande 
d'authentification locale, du type RADIUS Access-Request contenant un 
25 identifiant egal a 45. 

A l'etape suivante 27, le serveur proxy 10 recoit du serveur d'acces la reponse a 
1'authentification locale, foumie par 1'utilisateur, la verifie et la memorise. Si a 
l'etape suivante 28, la reponse est invalide (1'authentification locale a echoue), 

30 le serveur proxy peut refaire une tentative d'authentification en reprenant la 
procedure a l'etape 24. Si 1'authentification locale de 1'utilisateur n'a pas reussi 
a Tissue d'un nombre predefini de tentatives, le serveur proxy 10 peut selon la 
politique d'administration locale, envoyer a 1'utilisateur par 1' intermediate du 
serveur d'acces 9 un message de rejet du type RADIUS Access-Reject, ou 

35 poursuivre la procedure a l'etape 30 pour permettre a 1'utilisateur d'etre 
authentifie par un serveur d'authentification distant 15 mis en oeuvre par un 
fournisseur d'acces ou de services auquel 1'utilisateur veut acceder. 
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Si a l'etape 23 l'utilisateur ne doit pas etre authentifie localement, la procedure 
se poursuit egalement a l'etape 30. A cette etape, le serveur proxy 10 emet a 
destination d'un serveur d' authentication distant 15 aupres duquel l'utilisateur 
souhaite etre authentifie, une requSte d'acces 50, du type RADIUS Access- 
5 Request contenant un identifiant egal a 3 1, si le serveur 1 5 est de type RADIUS. 
Ce message est constitue a partir des informations contenues dans la requSte 
d'acces 41 memorisee par le serveur proxy 10 a l'6tape 22. 

A l'etape suivante 31, le serveur d'authentification distant 15 recoit et analyse 
10 ce message pour determiner le droit d'acces au service demande par 
l'utilisateur. A l'etape suivante 32, le serveur d'authentification emet un 
message de reponse 52 qui peut etre un message d' acceptation, de rejet ou de 
defi, selon les informations d'authentification contenues dans le message 50 
recu. Ainsi, conformement au protocole RADIUS, le message 52 peut etre de 
15 type Access-Accept, Access-Reject ou Access-Challenge et contient un 
identifiant 6gal a 31 correspondant a l'identifiant du message 50 recu. 

Les etapes suivantes de la procedure dependent de deux conditions (etape 33), a 
savoir si l'authentification locale de l'utilisateur a ete demandee au prealable ou 
20 non, et si l'authentification locale a ete demandee, si celle-ci a reussi ou echoue. 

Si l'authentification n'a pas ete demandee au prealable, le serveur proxy 10 qui 
recoit le message 52, traite ce message a l'etape 34 et envoie un message 54 au 
serveur d'acces 9. Ce message 54 correspond a une reponse au message 41 emis 

25 a l'etape 21 par le serveur d'acces. Ces messages comportent par exemple 
l'identifiant 128 (cas a) dans la figure 2b). Ainsi, si le message 52 emis par le 
serveur d'authentification distant 15 est un message d'acceptation (RADIUS 
Access-Accept), le serveur proxy 10 renvoie au serveur d'acces 9 un message 
d'acceptation (RADIUS Access- Accept). Si le message 52 emis par le serveur 

30 d'authentification distant 15 est un message de refus (RADIUS Access-Reject), 
le serveur proxy 10 renvoie au serveur d'acces 9 un message de refus (RADIUS 
Access-Reject) ou un message d'acceptation selon la politique locale du serveur 
proxy. Le message 52 peut egalement etre un message de defi si 
l'authentification de l'utilisateur par le serveur d'authentification distant 15 a 

35 6choue, ou si ce dernier a besoin de davantage d' informations d'authentification 
ou souhaite appliquer un mecanisme dynamique d'authentification. Dans ce cas, 
le message 54 transmis au serveur d'acces est un message de defi (RADIUS 
Access-Challenge). 
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A la reception du message 54 a l'etape 35, le serveur d'acces analyse le contenu 
du message, et s'il s'agit d'un message d'acceptation ou de refus, la procedure 
d'authentification prend fin et le serveur d'acces configure l'acces de 
5 l'utilisateur au reseau local 1, 2, et au reseau IP 5 en fonction de la reponse du 
serveur proxy 10. Si le message 54 est un message de defi, le serveur d'acces 
demande a l'utilisateur a l'etape 36 de fournir une reponse a la demande 
d'authentification du domaine administratif distant. A l'etape suivante 37, le 
serveur d'acces constitue une requete d'accds 57 contenant la reponse de 
10 l'utilisateur et l'envoie au serveur proxy 10. Cette requete d'acces est un 
message RADIUS Access-Request avec un identifiant egal a 10 (cas b) dans la 
figure 2b). 

A l'etape suivante 38, le serveur proxy recoit le message 57 et le retransmet au 
15 serveur d'authentification distant 15 dans un message de requdte 58, sous la 
forme d'un message RADIUS du type Access-Request avec un identifiant egal 
a 24 (cas c) dans la figure 2b). A l'etape suivante 39, le serveur 15 recoit et 
analyse le contenu du message 58 et emet a l'etape 40 suivante un message de 
reponse 60 dont le contenu depend de la reussite de l'authentification effectuee 
20 par le serveur 15. Ce message conserve l'identifiant 24 (cas d) dans la figure 
2b). Ainsi, le message 60 peut 6tre un message d'acception (RADIUS Access- 
Accept), de refus (RADIUS Access-Reject) ou un nouveau message de defi 
(RADIUS Access-Challenge) 

25 La proc6dure d'authentification reprend ensuite a partir de l'etape 34 au cours 
de laquelle le serveur proxy 10 traite et retransmet le message 60 recu au 
serveur d'acces sous la forme d'un message 54. L'identifiant du message 60 
recu, egal a 24, est remplace par 10 pour correspondre a celui 57 emis par le 
serveur d'acces 9 (cas e) dans la figure 2b). 



30 
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La procedure d'authentification se termine a l'etape 35 si le message 54 qui est 
transmis au serveur d'acces 9 est un message d'acceptation ou de refus et 
contient le resultat de l'authentification effectuee par le serveur 
d'aumentification distant 15 (pas d'authentification locale). Si par contre le 
message 54 est un nouveau message de defi, la procedure se poursuit a l'etape 

Si a l'etape 33, l'authentification locale a ete demandee et a reussi, la procedure 
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comprenant les etapes 34 a 40 est egalement executee, mais avec des messages 
contenant des numeros d' identification differents (messages correspondants aux 
cas al) a el) dans la figure 2b). Ainsi, le message 52 contenant l'identifiant 31 
est transforme a l'etape 34 par le serveur proxy en un message 54 contenant 
5 l'identifiant 45 et le resultat de 1' identification locale. A l'etape 37, l'identifiant 
45 du message 57 devient 20. A l'etape suivante 38, l'identifiant 20 du message 
58 devient 48. A l'6tape 40, l'identifiant 48 reste inchange. A l'etape suivante 
34, l'identifiant 48 du message devient 20. 

10 La procedure d'authentification se termine a l'etape 35 si le message 54 qui est 
transmis au serveur d'acces 9 est du type acceptation ou refus, contenant un 
attribut precisant le resultat des authentifications locale (reussite) et distante. Si 
par contre le message 54 est un nouveau message de defi, la procedure se 
poursuit a l'etape 36. 



15 



A Tissue de la procedure d'authentification, si l'authentification distante a 
reussi, le message 54 est de type acceptation, et si elle a echoue, ce message 
peut dtre de type acceptation ou refus selon la politique d' administration locale. 

20 Si a l'etape 33, l'authentification locale a ete demandee et a echoue, la 
procedure comportant les Stapes 34 a 40 est egalement executee, avec des 
messages contenant des numeros d' identification differents (messages 
correspondants aux cas a2) a e2) dans la figure 2b). Ainsi, le message 52 
contenant l'identifiant 31 est transforme a l'etape 34 par le serveur proxy en un 

25 message 54 contenant l'identifiant 45 et le resultat de l'identification locale. A 
l'etape 37, l'identifiant 45 du message 57 devient 30. A l'etape suivante 38, 
l'identifiant 30 du message 58 devient 96. A l'etape 40, l'identifiant 96 reste 
inchange. A l'etape suivante 34, l'identifiant 96 du message devient 30. 

30 La procedure d'authentification se termine a l'etape 35 si le message 54 qui est 
transmis au serveur d'acces 9 est du type acceptation ou refus, contenant un 
attribut precisant le resultat des authentifications locale (6chec) et distante. Si 
par contre le message 54 est un nouveau message de defi, la procedure se 
poursuit a l'etape 36. 



35 



A l'issue de la procedure d'authentification, le message 54 qui est envoye au 
serveur d'acces 9 peut 6tre de type acceptation (meme si les authentifications 
locale et distante ont echoue) ou refus selon la politique d'administration locale. 
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En fonction du resultat de la procedure d'authentification, le serveur d'acces 9 
configure ensuite l'acces de l'utilisateur d'une maniere adequate et peut 
l'informer sur le type de connexion a laquelle il a droit. 

Grace a ces dispositions, les procedures locale et distante d'authentification 
d'un utilisateur sont totalement independantes. Chaque domaine administratif 
est done totalement libre d'imposer ou non une procedure d'authentification. 



Dans un mode de r6alisation de l'invention, on utilise deux attributs du type 
"Vendor Specific" des messages RADIUS prevus dans le protocols Le premier 
de ces deux attributs appele "Local_Challenge" est inclus dans les messages de 
d6fi envoyes par le serveur proxy 10 au serveur d'acces 9. Cet attribut est utilise 
pour indiquer au serveur d'acces si oui ou non il est a l'origine du message. En 
fonction de la presence ou non de cet attribut, le serveur d'acces precise a 
l'utilisateur s'il s'agit d'une authentification locale ou distante pour obtenir une 
reponse adequate a un message de defi. 

Le second attribut appele "Auth_Status" est inclus dans les messages 
d'acceptation envoyes par le serveur proxy pour cldturer la procedure 
20 d'authentification de l'utilisateur et pour indiquer au serveur d'acces les 
resultats d'authentification locale et distante. 

Cette procedure est parfaitement adaptee a un acces au reseau Internet par 
l'intermediaire d'un reseau local ouvert de type WLAN, par exemple Wi-Fi 

25 dont l'acces est contrdle par son proprietaire. Ce reseau local peut proposer des' 
services locaux, tels que des services de fourniture d'informations sur le lieu ou 
le reseau local est accessible, par exemple des plans, des listes d'adresses utiles, 
etc. Pour acceder au reseau Internet, les utilisateurs qui se connectent a ce 
reseau local doivent en outre proceder a une demande d'acces aupres de leur 

30 fournisseur d'acces. 



Lorsqu'un utilisateur muni d'un terminal se trouve dans la zone de couverture 
du reseau local WLAN, et qu'il lance le logiciel de navigation, celui-ci est 
automatiquement redirige sur un serveur Web du serveur d'acces local 9. Dans 
une page d'accueil du serveur Web, les utilisateurs sont invites a introduire un 
identifiant et un mot de passe d'acces au reseau local s'ils en ont un. S'ils 
souhaitent acceder au reseau Internet, ils doivent selectionner un fournisseur 
d'acces dans une liste, puis introduire un identifiant et un mot de passe d'acces 
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correspondant au fournisseur d'acces selectionne. 

Les informations saisies par l'utilisateur sont transmises par le serveur d'acces 9 
au serveur proxy 10 du reseau local. 

5 Si l'utilisateur a introduit un identifiant et un mot de passe d'acces au reseau 
local, le serveur proxy 10 du r6seau local declenche la procedure 
^identification locale et garde en memoire le resultat de cette authentification. 
Puis il declenche la procedure d' authentification de l'utilisateur aupres du 
serveur d' authentification 15 du fournisseur d'acces selectionne par 

10 l'utilisateur. 

Selon le resultat des authentifications locale et distante, le serveur proxy envoie 
un message d' acceptation, ou de reras si les authentifications locale et distante 
ont toutes les deux echoue. Dans ce dernier cas, le serveur d'acces n'autorise 
1 5 pas l'utilisateur a acceder a des services locaux ou distants. 

Si l'utilisateur a 6te authentifie uniquement localement ou uniquement aupres 
du fournisseur d'acces, le serveur d'acces ne lui donne acces qu'aux services 
correspondants. Et si les deux authentifications ont reussi, le serveur d'acces 
donne acces a l'utilisateur a la fois aux services locaux et distants. 

20 

De m6me, si l'utilisateur n'a pas demande une authentification locale, seule une 
authentification distante est effectuee, et si celle-ci reussit, le serveur d'acces lui 
configure un acces au reseau Internet. 

25 La qualite de service QoS attribuee a l'utilisateur dans le reseau local peut 
egalement etre adaptee par le serveur d'acces 9 en fonction du resultat de 
1' authentification locale. 
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REVENDICATIONS 

1. Procede de gestion d'autorisation d'un utilisateur lors d'une 
tentative d'acces a un reseau de transport IP (5) par rintermediaire d'un reseau 
5 d'acces (1, 2), ce procede comprenant des Stapes au cours desquelles : 

- un terminal (11, 12, 13) d'utilisateur emet a destination d'un fournisseur 
d'acces ou de service IP (6, 7, 8) une requete d'acces contenant des donnees 
d'authentification de l'utilisateur aupres du fournisseur d'acces ou de service 
IP, qui est transmise par rintermediaire d'un serveur d'acces (9) du reseau 

10 d'acces (1, 2) et du reseau de transport IP (5), en vue d'etre adress6e a un 
serveur d'authentification distant (15) du fournisseur d'acces ou de service 

IPj 

- sur reception de la requete d'acces, le serveur d'acces (9) emet une requete 
RADIUS conforme au protocole RADIUS a un serveur proxy (10) du reseau 

15 d'acces (1,2), 

- sur reception de la requete RADIUS, le serveur proxy emet une demande 
d'autorisation d'acces au serveur d'authentification distant (15), 

- le serveur d'authentification distant (15) execute une procedure 
d'authentification de l'utilisateur, sur la base des donn6es d'authentification 

20 contenues dans la requete d'acces, et transmet en reponse au serveur proxy 
un message de reponse contenant le resultat de la procedure 
d'authentification de l'utilisateur, 
caracterise en ce qu'il comprend en outre des etapes au cours desquelles : 

- le serveur proxy determine pour chaque requete RADIUS, recue du serveur 
25 d'acces (9) et correspondant a une requete d'acces 6mise par un terrninal 

d'utilisateur, si une authentification locale de l'utilisateur emetteur de la 
requete d'acces, au niveau du reseau local (1, 2) doit etre effectuee, 

- si une authentification locale de l'utilisateur doit etre effectuee, le serveur 
proxy emet a destination du serveur d'acces (9) une demande de donnees 

30 d'authentification qui est retransmise au terminal de l'utilisateur, recoit un 
message de reponse du terminal d'utilisateur par rintermediaire du serveur 
d'acces, et execute une procedure d'authentification locale de l'utilisateur, 
sur la base des donnees d'authentification contenues dans le message de 
reponse. 

35 

2. Procede selon la revendication 1, 
caracterise en ce que la demande de donnees d'authentification emise par le 
serveur proxy (10) a destination du terminal de l'utilisateur (11, 12, 13) si une 
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authentification locale de l'utilisateur doit 6tre effectuee, est un message de defi 
contenant un nombre aleatoire. 

3. Procede selon la revendication 2, 

5 caracterise en ce que le message de defi contient une indication permettant au 
terminal de l'utilisateur de d6terminer qu'il concerne une authentification locale 
de l'utilisateur. 

4. Proc6de selon Tune des revendications 1 a 3, 

10 caracterise en ce que 1' authentification distante de l'utilisateur par le serveur 
d'authentification distant (15) comprend des etapes au cours desquelles : 

- le serveur d' authentification distant 6met en direction de l'utilisateur un 
message de d6fi contenant un nombre aleatoire, 

- le serveur proxy (10) retransmet le message de defi emis par le serveur 
15 d'authentification distant en direction de l'utilisateur et recoit dans un 

message de reponse les donnees d'authentification de l'utilisateur aupres du 
serveur d'authentification distant, 

- le serveur proxy (10) retransmet au serveur d'authentification distant le 
message de reponse emis par le terminal de l'utilisateur, 

- le serveur proxy (10) recoit du serveur d'authentification distant un message 
de resultat de 1 'authentification de l'utilisateur. 



!0 



5. Proc6de selon l'une des revendications 1 a 4, 

caracterise en ce que le serveur proxy (10) determine quels droits d'acces 
5 attribuer a l'utilisateur en fonction du resultat des authentifications locale et 
distante de l'utilisateur. 

6. Systeme de gestion d'autorisation d'un utilisateur lors d'une 
tentative d'acces d'un terminal d'utilisateur a un fournisseur d'acces ou de 

D service IP (6, 7, 8) par l'mtermediaire d'un reseau de transport IP (5), le 
systeme comprenant : 

- des reseaux d'acces (1, 2) auxquels sont connectes les terminaux 
d'utilisateurs, 

- des passerelles IP (3, 4) assurant la liaison respectivement entre les reseaux 
5 d'acces (1, 2) et le reseau de transport IP (5), 

- au moins un serveur d'acces (9) par reseau d'acces, concu pour emettre a la 
demande des terminaux d'utilisateur des requetes d'acces RADIUS 
conformes au protocole RADIUS, 
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- au moins un serveur d'authentification distant (15) pour chacun des 
fournisseurs d'acces ou de service IP (6, 7, 8), concu pour authentifier les 
utilisateurs en fonction de donnees d'authentification contenues dans des 
requetes d'acces (50, 58) recues par le serveur d'authentification, et 

5 - un serveur proxy (10) connecte au reseau de transport IP concu pour 
retransmettre chaque requete d'acces RADIUS, emise par l'un des serveurs 
d'acces (9) a la demande d'un utilisateur, vers un serveur d'authentification 
distant (15) de fournisseur d'acces ou de service IP indiqu6 dans la requete 
d'acces, et retransmettre vers les serveurs d'acces les reponses 
10 d'authentification fournies par les serveurs d'authentification distant (15), 
caracterise en ce que le serveur proxy (10) comprend : 

- des moyens pour determiner pour chaque requete d'acces RADIUS recue 
d'un serveur d'acces (9) a la demande d'un utilisateur, si une authentification 
locale de l'utilisateur emetteur de la requete d'acces doit ou non etre 

5 effectuee au niveau du reseau local (1,2), 

- des moyens pour emettre par l'mtermediaire d'un serveur d'acces a 
destination d'un terminal d'utilisateur devant etre authentifie localement, un 
message de demande de donnees d'authentification, et pour recevoir en 
reponse du terminal d'utilisateur un message de reponse contenant les 

20 donnees d'authentification demandees, et 

- des moyens pour executer une procedure d'authentification locale de 
l'utilisateur, sur la hase des informations d'authentification contenues dans le 
message de reponse. 

25 7. Systeme selon la revendication 6, 

caracterise en ce que le serveur proxy (10) comprend en outre des moyens pour 
determiner un resultat global d'authentification en fonction du resultat de 
l'authentification locale de l'utilisateur et de la reponse d'authentification de 
l'utilisateur fournie par le serveur d'authentification (15), et pour retransmettre 

30 le r6sultat global d'authentification vers le serveur d'acces (9). 

8. Systeme selon la revendication 6 ou 7, 

caracterise en ce que chaque serveur d'acces (9) comprend un client RADIUS et 
le serveur proxy comprend un client et un serveur RADIUS, pour echanger des 
35 messages conformes au protocole RADIUS. 

9. Systeme selon Tune des revendications 6 a 8, 

caracterise en ce que le message de demande de donnees d'authentification 
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emis par le serveur proxy (10) pour authentifier localement l'utilisateur est un 
message de defi, le serveur proxy comportant des moyens pour generer un 
nombre aleatoire qui est insere dans le message de defi, et des moyens pour 
verifier la reponse au message de defi recue du terminal de l'utilisateur. 

10. Systeme selon Tune des revindications 6 k 9, 
caracterise en ce que le serveur proxy (10) comprend des moyens pour 
determiner quels droits d'acces attribuer a l'utilisateur en fonction du resultat 
des authentifications locale et distante de l'utilisateur. 
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Pour gerer l'autorisation d'un utilisateur lors d'une tentative d'acces a un r6seau 
de transport IP (5) par l'intermediaire d'un reseau d'acces (1, 2), un terminal (11, 
12, 13) d'utilisateur emet a destination d'un fournisseur d'acces (6, 7, 8) une 
requete d'acces contenant des donn6es d'authentification de I'utilisateur aupres 
du fournisseur d'acces, qui est transmise a un serveur d'acces (9) du reseau 
d'acces (1, 2), en vue d'etre adressee a un serveur d'authentification distant (15) 
du fournisseur d'acces ; sur reception de la requete d'acces, le serveur d'acces (9) 
emet une requete RADIUS a un serveur proxy (10) du reseau d'acces (1, 2) qui 
determine si I'utilisateur doit etre authentifie localement, et si tel est le cas, le 
serveur proxy transmet au serveur d'acces (9) une demande de donnees 
d'authentification a adresser au terminal de I'utilisateur, et execute une procedure 
d'authentification locale de I'utilisateur, sur la base des donnees 
d'authentification fournies par I'utilisateur. 
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